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Abstract 
This document describes the conventions for using the cryptographic 
algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and 
GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS 


is used for digital signature, digest, authentication, and encryption 
of arbitrary message contents. 
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Introduction 


The Cryptographic Message Syntax [CMS] is used for digital signature, 
digest, authentication, and encryption of arbitrary message contents. 
This companion specification describes the use of cryptographic 
algorithms GOST 28147-89 [GOST28147], GOST R 34.10-94 [GOST3431095, 
GOSTR341094], GOST R 34.10-2001 [GOST3431004, GOSTR341001], and GOST 
R 34.11-94 [GOST3431195, GOSTR341194] in CMS, as proposed by the 
CRYPTO-PRO Company for the "Russian Cryptographic Software 
Compatibility Agreement" community. This document does not describe 
these cryptographic algorithms; they are defined in corresponding 
national standards. 


The CMS values are generated using ASN.1 [X.208-88], using BER 
encoding [X.209-88]. This document specifies the algorithm 
identifiers for each algorithm, including ASN.1 for object 
identifiers and any associated parameters. 


The fields in the CMS employed by each algorithm are identified. 
1.  Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Message Digest Algorithms 


This section specifies the conventions for using the digest algorithm 
GOST R 34.11-94 employed by CMS. 


Digest values are located in the DigestedData digest field and the 
Message Digest authenticated attribute. In addition, digest values 
are input to signature algorithms. 


1. Message Digest Algorithm GOST R 34.11-94 


The hash function GOST R 34.11-94 has been developed by "GUBS of 
Federal Agency Government Communication and Information" and "All- 
Russian Scientific and Research Institute of Standardization". The 
algorithm GOST R 34.11-94 produces a 256-bit hash value of the 
arbitrary finite bit-length input. This document does not contain 
the full GOST R 34.11-94 specification, which can be found in 
[GOSTR341194] in Russian. [Schneier95], ch. 18.11, p. 454, contains 
a brief technical description in English. 
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The hash algorithm GOST R 34.11-94 has the following identifier: 


id-GostR3411-94 OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
gostr3411(9) ) 


The AlgorithmIdentifier parameters field MUST be present, and the 
parameters field MUST contain NULL.  Implementations MAY accept the 
GOST R 34.11-94 AlgorithmIdentifiers with absent parameters as well 
as NULL parameters. 


This function is always used with default parameters id-GostR3411- 
94-CryptoProParamSet (see Section 8.2 of [CPALGS]). 


When the Message Digest authenticated attribute is present, the 
DigestedData digest contains a 32-byte digest in little-endian 
representation: 


GostR3411-94-Digest ::= OCTET STRING (SIZE (32)) 
3. Signature Algorithms 


This section specifies the CMS procedures for the GOST R 34.10-94 and 
GOST R 34.10-2001 signature algorithms. 


Signature algorithm identifiers are located in the SignerInfo 
SignatureAlgorithm field of SignedData. Also, signature algorithm 
identifiers are located in the SignerInfo signatureAlgorithm field of 
countersignature attributes. 


Signature values are located in the SignerInfo signature field of 
SignedData. Also, signature values are located in the SignerInfo 
signature field of countersignature attributes. 


3.1. Signature Algorithm GOST R 34.10-94 


GOST R 34.10-94 has been developed by "GUBS of Federal Agency 
Government Communication and Information" and "All-Russian Scientific 
and Research Institute of Standardization". This signature algorithm 
MUST be used conjointly with the GOST R 34.11-94 message digest 
algorithm. This document does not contain the full GOST R 34.10-94 
Specification, which is fully described in [GOSTR341094] in Russian; 
and a brief description in English can be found in [Schneier95], ch. 
20.3, p. 495. 


The GOST R 34.10-94 signature algorithm has the following public key 
algorithm identifier: 
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id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94 


id-GostR3410-94 is defined in Section 2.3.1 of [CPPK]. 


The signature algorithm GOST R 34.10-94 generates a digital signature 
in the form of two 256-bit numbers, r’ and s. Its octet string 
representation consists of 64 octets, where the first 32 octets 
contain the big-endian representation of s and the second 32 octets 
contain the big-endian representation of r’. 


GostR3410-94-Signature ::= OCTET STRING (SIZE (64)) 
3.2. Signature Algorithm GOST R 34.10-2001 


GOST R 34.10-2001 has been developed by "GUBS of Federal Agency 
Government Communication and Information" and "All-Russian Scientific 
and Research Institute of Standardization". This signature algorithm 
MUST be used conjointly with GOST R 34.11-94. This document does not 
contain the full GOST R 34.10-2001 specification, which is fully 
described in [GOSTR341001]. 


The signature algorithm GOST R 34.10-2001 has the following public 
key algorithm identifier: 


id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001 
id-GostR3410-2001 is defined in Section 2.3.2 of [CPPK]. 


The signature algorithm GOST R 34.10-2001 generates a digital 
signature in the form of two 256-bit numbers, r and s. Its octet 
string representation consists of 64 octets, where the first 32 
octets contain the big-endian representation of s and the second 32 
octets contain the big-endian representation of r. 


GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) 
4. Key Management Algorithms 


This chapter describes the key agreement and key transport 
algorithms, based on the VKO GOST R 34.10-94 and VKO GOST R 34.10- 
2001 key derivation algorithms, and the CryptoPro and GOST 28147-89 
key wrap algorithms, described in [CPALGS]. They MUST be used only 
with the content encryption algorithm GOST 28147-89, defined in 
Section 5 of this document. 
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4.1. Key Agreement Algorithms 


This section specifies the conventions employed by CMS 
implementations that support key agreement using both the VKO GOST R 
34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 


Key agreement algorithm identifiers are located in the EnvelopedData 
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 
keyEncryptionAlgorithm fields. 


Wrapped content-encryption keys are located in the EnvelopedData 
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 
encryptedKey field. Wrapped message-authentication keys are located 
in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 
RecipientEncryptedKeys encryptedKey field. 


4.1.1. Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public 
Keys 


The EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used 
as follows: 


The version MUST be 3. 


The originator MUST be the originatorKey alternative. The 
originatorKey algorithm field MUST contain the object identifier 
id-GostR3410-94 or id-GostR3410-2001 and corresponding parameters 
(defined in Sections 2.3.1, 2.3.2 of [CPPK]). 


The originatorKey publicKey field MUST contain the sender's public 
key. 


keyEncryptionAlgorithm MUST be the id-GostR3410-94-CryptoPro-ESDH 
or the id-GostR3410-2001-CryptoPro-ESDH algorithm identifier, 
depending on the recipient public key algorithm. The algorithm 
identifier parameter field for these algorithms is 
KeyWrapAlgorithm, and this parameter MUST be present. The 
KeyWrapAlgorithm denotes the algorithm and parameters used to 
encrypt the content-encryption key with the pairwise key- 
encryption key generated using the VKO GOST R 34.10-94 or the VKO 
GOST R 34.10-2001 key agreement algorithms. 


The algorithm identifiers and parameter syntax is: 


id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::- 
( iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 
gostR3410-94-CryptoPro-ESDH(97) ) 
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id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
gostR3410-2001-CryptoPro-ESDH(96) } 


KeyWrapAlgorithm ::= AlgorithmIdentifier 


When keyEncryptionAlgorithm is id-GostR3410-94-CryptoPro-ESDH, 
KeyWrapAlgorithm algorithm MUST be the id-Gost28147-89-CryptoPro- 
KeyWrap algorithm identifier. 


id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
keyWrap(13) cryptoPro(1) ) 


The CryptoPro Key Wrap algorithm is described in Sections 6.3 and 
6.4 of [CPALGS]. 


When keyEncryptionAlgorithm is id-GostR3410-2001-CryptoPro-ESDH, 
KeyWrapAlgorithm algorithm MUST be either the id-Gost28147-89- 
CryptoPro-KeyWrap or id-Gost28147-89-None-KeyWrap algorithm 
identifier. 


id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
keyWrap(13) none(0) ) 


The GOST 28147-89 Key Wrap algorithm is described in Sections 6.1 
and 6.2 of [CPALGS]. 


KeyWrapAlgorithm algorithm parameters MUST be present. The syntax 
for KeyWrapAlgorithm algorithm parameters is 


Gost28147-89-KeyWrapParameters ::= 


SEQUENCE { 

encryptionParamSet Gost28147-89-ParamSet, 

ukm OCTET STRING (SIZE (8)) OPTIONAL 
} 
Gost28147-89-ParamSet ::= OBJECT IDENTIFIER 


Gost28147-89-KeyWrapParameters ukm MUST be absent. 


KeyAgreeRecipientInfo ukm MUST be present and contain eight 
octets. 


encryptedKey MUST encapsulate Gost28147-89-EncryptedKey, where 
maskKey MUST be absent. 
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Gost28147-89-EncryptedKey ::= SEQUENCE { 
encryptedKey Gost28147-89-Key, 
maskKey [0] IMPLICIT Gost28147-89-Key 
OPTIONAL, 
macKey Gost28147-89-MAC 


} 


Using the secret key corresponding to the originatorKey publicKey and 
the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO 
GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the 
KEK. 


Then the key wrap algorithm, specified by KeyWrapAlgorithm, is 
applied to produce CEK ENC, CEK MAC, and UKM. Gost28147-89- 
KeyWrapParameters encryptionParamSet is used for all encryption 
operations. 


The resulting encrypted key (CEK ENC) is placed in the Gost28147-89- 
EncryptedKey encryptedKey field, its mac (CEK MAC) is placed in the 
Gost28147-89-EncryptedKey macKey field, and UKM is placed in the 
KeyAgreeRecipientInfo ukm field. 


4.2. Key Transport Algorithms 
This section specifies the conventions employed by CMS 
implementations that support key transport using both the VKO GOST R 
34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 


Key transport algorithm identifiers are located in the EnvelopedData 
RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 


Key transport encrypted content-encryption keys are located in the 
EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 


field. 


4.2.1. Key Transport Algorithm Based on GOST R 34.10-94/2001 Public 
Keys 


The EnvelopedData RecipientInfos KeyTransRecipientInfo field is used 
as follows: 


The version MUST be 0 or 3. 


keyEncryptionAlgorithm and parameters MUST be identical to the 
recipient public key algorithm and parameters. 
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encryptedKey encapsulates GostR3410-KeyTransport, which consists 
of encrypted content-encryption key, its MAC, GOST 28147-89 
algorithm parameters used for key encryption, the sender's 
ephemeral public key, and UKM (UserKeyingMaterial; see [CMS], 
Section 10.2.6). 


transportParameters MUST be present. 


ephemeralPublicKey MUST be present and its parameters, if present, 
MUST be egual to the recipient public key parameters; 


GostR3410-KeyTransport ::= SEQUENCE (1 
sessionEncryptedKey Gost28147-89-EncryptedKey, 
transportParameters 

[0] IMPLICIT GostR3410-TransportParameters OPTIONAL 

} 


GostR3410-TransportParameters ::= SEQUENCE { 
encryptionParamSet OBJECT IDENTIFIER, 
ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, 
ukm OCTET STRING 


} 


Using the secret key corresponding to the GostR3410- 
TransportParameters ephemeralPublicKey and the recipient's public 
key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 
(described in [CPALGS]) is applied to produce the KEK. 


Then the CryptoPro key wrap algorithm is applied to produce CEK ENC, 
CEK MAC, and UKM.  GostR3410-TransportParameters encryptionParamSet 
is used for all encryption operations. 


The resulting encrypted key (CEK ENC) is placed in the Gost28147-89- 
EncryptedKey encryptedKey field, its mac (CEK MAC) is placed in the 
Gost28147-89-EncryptedKey macKey field, and UKM is placed in the 
GostR3410-TransportParameters ukm field. 


5. Content Encryption Algorithms 


This section specifies the conventions employed by CMS 
implementations that support content encryption using GOST 28147-89. 


Content encryption algorithm identifiers are located in the 


EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 
EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 
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Content encryption algorithms are used to encipher the content 
located in the EnvelopedData EncryptedContentInfo encryptedContent 
field and the EncryptedData EncryptedContentInfo encryptedContent 
field. 


5.1. Content Encryption Algorithm GOST 28147-89 


This section specifies the use of GOST 28147-89 algorithm for data 
encipherment. 


GOST 28147-89 is fully described in [GOST28147] (in Russian). 


This document specifies the following object identifier (OID) for 
this algorithm: 


id-Gost28147-89 OBJECT IDENTIFIER ::= 
( iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
gost28147-89(21) ) 


Algorithm parameters MUST be present and have the following 
structure: 


Gost28147-89-Parameters ::- 
SEQUENCE 4 
iv Gost28147-89-IV, 
encryptionParamSet OBJECT IDENTIFIER 
} 


Gost28147-89-IV ::= OCTET STRING (SIZE (8)) 


encryptionParamSet specifies the set of corresponding Gost28147-89- 
ParamSetParameters (see Section 8.1 of [CPALGS]) 


6. MAC Algorithms 
This section specifies the conventions employed by CMS 
implementations that support the message authentication code (MAC) 


based on GOST R 34.11-94. 


MAC algorithm identifiers are located in the AuthenticatedData 
macAlgorithm field. 


MAC values are located in the AuthenticatedData mac field. 
6.1. HMAC with GOST R 34.11-94 


HMAC_GOSTR3411 (K,text) function is based on hash function GOST R 
34.11-94, as defined in Section 3 of [CPALGS]. 
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This document specifies the following OID for this algorithm: 


id-HMACGostR3411-94 OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
hmacgostr3411(10) ) 


This algorithm has the same parameters as the GOST R 34.11-94 digest 
algorithm and uses the same OIDs for their identification (see 
[CPPK]). 


7. Use with S/MIME 


This section defines the use of the algorithms defined in this 
document with S/MIME [RFC3851]. 


7.1. Parameter micalg 


When using the algorithms defined in this document, micalg parameter 
SHOULD be set to "gostr3411-94"; otherwise, it MUST be set to 
"unknown". 


7.2. Attribute SMIMECapabilities 


The SMIMECapability value that indicates support for the GOST R 
34.11-94 digest algorithm is the SEQUENCE with the capabilityID field 
containing the object identifier id-GostR3411-94 and no parameters. 
The DER encoding is: 


30 08 06 06 2A 85 03 02 02 09 


The SMIMECapability value that indicates support for the GOST 
28147-89 encryption algorithm is the SEOUENCE with the capabilityID 
field containing the object identifier id-Gost28147-89 and no 
parameters. The DER encoding is: 


30 08 06 06 2A 85 03 02 02 15 


If the sender wishes to indicate support for a specific parameter 
set, SMIMECapability parameters MUST contain the Gost28147-89- 
Parameters structure.  Recipients MUST ignore the Gost28147-89- 
Parameters iv field and assume that the sender supports the 
parameters specified in the Gost28147-89-Parameters 
encryptionParamSet field. 


The DER encoding for the SMIMECapability, indicating support for GOST 


28147-89 with id-Gost28147-89-CryptoPro-A-ParamSet (see [CPALGS]), 
is: 
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8. 


9. 


30 ID 06 06 2A 85 03 02 02 15 30 13 04 08 00 00 
00 00 00 00 00 00 06 07 2A 85 03 02 02 1F 01 


Security Considerations 


Conforming applications MUST use unigue values for ukm and iv. 
Recipients MAY verify that ukm and iv, specified by the sender, are 
unigue. 


It is RECOMMENDED that software applications verify that signature 
values, subject public keys, and algorithm parameters conform to 
[GOSTR341001] and [GOSTR341094] standards prior to their use. 


Cryptographic algorithm parameters affect algorithm strength. The 
use of parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 
Security Considerations section of [CPALGS]). 


Use of the same key for signature and key derivation is NOT 
RECOMMENDED. When signed CMS documents are used as an analogue to a 
manual signing, in the context of Russian Federal Electronic Digital 
Signature Law [RFEDSL], signer certificate MUST contain the keyUsage 
extension, it MUST be critical, and keyUsage MUST NOT include 
keyEncipherment or keyAgreement (see [PROFILE], Section 4.2.1.3). 
Application SHOULD be submitted for examination by an authorized 
agency in appropriate levels of target of evaluation (TOE), according 
to [RFEDSL], [RFLLIC], and [CRYPTOLIC]. 


Examples 


Examples here are stored in the same format as the examples in 
[RFC4134] and can be extracted using the same program. 


If you want to extract without the program, copy all the lines 
between the s [sen and "pem markers, remove any page breaks, and remove 
the "|" in the first column of each line. The result is a valid 
Base64 blob that can be processed by any Base64 decoder. 


1. Signed Message 
This message is signed using the sample certificate from Section 4.2 
of [CPPK]. The public key (x,y) from the same section can be used to 


verify the message signature. 


0 296: SEQUENCE { 


4 9: OBJECT IDENTIFIER signedData 
15 281: [0] 4 

19 277: SEQUENCE { 
23 li INTEGER 1 
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26 
28 
30 
38 


40 
42 
53 
55 


69 
72 
75 
78 
81 
83 
85 
87 
92 


116 
118 
120 
125 


136 
138 
140 
145 


149 
151 
153 
164 


192 


210 
212 
220 
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18: 
16: 


16: 


SET 
SE 


OBJECT IDENTIFIER id-GostR3411-94 


N 
} 


} 
SEQ 


Using GOST with CMS 


{ 
QUENCE { 


ULL 


UENCE { 


OBJECT IDENTIFIER data 


[0 


Jat 


May 2006 


OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 OA 


) 

) 
SET 
SE 
I 
S 


S 


Chudov 


{ 
QUENCE { 
NTEGER 1 
EQUENCE { 
SEQUENCE { 
SET { 


SEQUENCE { 


OBJECT IDENTIFIER commonName 


UTF8String 'GostR3410-2001 example’ 


} 
} 
SET { 


SEQUENCE { 


OBJECT IDENTIFIER organizationName 


UTF8String 'CryptoPro' 


} 
} 
SET { 


SEQUENCE { 


OBJECT IDENTIFIER countryName 


PrintableString 'RU' 


) 
} 
SET { 


SEQUENCE { 


OBJECT IDENTIFIER emailAddress 


IA5String ’GostR3410-2001@example.com’ 


} 
} 
} 
INTEGER 


2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 


} 
EQUENCE { 


OBJECT IDENTIFIER id-GostR3411-94 


NULL 
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: } 
222 10: SEQUENCE { 


224 6: OBJECT IDENTIFIER id-GostR3410-2001 
232 0: NULL 

E } 
234 64: OCTET STRING 


CO C3 42 D9 3F 8F FE 25 11 11 88 77 BF 89 C3 DB 
83 42 04 D6 20 F9 68 2A 99 F6 FE 30 3B E4 F4 C8 
F8 D5 B4 DA FB El C6 91 67 34 1F BC A6 7A OD 12 
7B FD 10 25 C6 51 DB 8D B2 F4 8C 71 7E ED 72 A9 


| >GostR3410-2001-signed.bin 

| MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG 

| 9wOBBwGgDgOMc2Ft cGxl IHRleHOKMYHkMIHhAgEBMI GBMGOxHzAdBgNVBAMMF kdv 

| c3RSMz0xMC0yMDAxIGV4YW1wbGUxE jAQBgNVBAOMCUNyeXB0b1BybzELMAKGA1UE 

| BhMCULUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0 yMDAxQGV4 YW1wbGUuY29t 
AhAr9cYewhG9F8fclGUmtCAhMAOGBiqFAwICCQUAMAOGBiqFAwICEWUABEDAwOLZ 
PA/*JRERiHe/icPbgOIEliD5aCqZ9v4wO-*TOyPjVtNr74caRZzQfvKZ6DRJ7/RAl 

| x I HbjbLOjHF-7XKp 

| <GostR3410-2001-signed.bin 


9.2.  Enveloped Message Using Key Agreement 
This message is encrypted using the sample certificate from Section 
4.2 of [CPPK] as a recipient certificate. The private key 'd' from 


the same section can be used to decrypt this message. 


O 420: SEQUENCE (1 


4 9: OBJECT IDENTIFIER envelopedData 

15 405: [0] 4 

19 401: SEOUENCE 4 
23 ls INTEGER 2 
26 336: SET ( 

30 332: [1] ( 

34 qs INTEGER 3 

34 kod: [0] 4 

39 9%: [1] 4 

41 28: SEOUENCE 4 

43 6: OBJECT IDENTIFIER id-GostR3410-2001 
sl 18: SEOUENCE 4 

53 Ta OBJECT IDENTIFIER 

E id-GostR3410-2001-CryptoPro-XchA-ParamSet 

62 TS OBJECT IDENTIFIER 
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71 67: 
74 64: 

140 TO: 
142 

152 30 
154 

162 20: 
164 

173 

175 

184 179 
187 176 
190 129 
193 109: 
195 31: 
197 29: 
199 

204 22: 
228 18: 
230 16: 
232 

237 

248 1 
250 

252 

257 

261 41: 
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id-GostR3411-94-CryptoProParamSet 
} 
} 
BIT STRING, encapsulates { 
OCTET STRING 
B3 55 39 FA 67 81 97 2B A5 C4 D9 84 1F 27 FB 81 
ED 08 32 E6 9A D4 F2 00 78 B8 FF 83 64 EA D2 1D 
BO 78 3C 7D FE 03 Cl F4 06 E4 3B CC 16 B9 C5 F6 
F6 19 37 1C 17 B8 AO AA C7 D1 Al 94 B3 A5 36 20 
} 
} 
} 
[1] { 
OCTET STRING 2F FO F6 Dl 86 4B 32 8A 
} 


SEQUENCE { 
OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-ESDH 
SEQUENCE { 
OBJECT IDENTIFIER id-Gost28147-89-None-KeyWrap 
SEQUENCE { 


OBJECT IDENTIFIER 
id-Gost28147-89-CryptoPro-A-ParamSet 
} 
} 
} 
SEQUENCE { 
SEQUENCE { 
SEQUENCE { 
SEQUENCE { 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER commonName 
UTF8String 'GostR3410-2001 example’ 
} 
} 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER organizationName 
UTF8String 'CryptoPro' 
} 
} 
SET { 
SEQUENCE { 
OBJECT IDENTIFIER countryName 
PrintableString 'RU' 
} 
} 
SET { 
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263 39: SEQUENCE { 
265 O38 OBJECT IDENTIFIER emailAddress 
276 26: IA5String ’GostR3410-2001@example.com’ 
: } 
} 
: } 
304 16: INTEGER 


2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 


a } 
322 42: OCTET STRING, encapsulates { 


324 40: SEQUENCE { 


326 32: OCTET STRING 
S 16 A3 1C E7 CE 4E E9 OD F1 EC 74 69 04 68 1E C7 
: 9F 3A ED B8 3B 1F 1D 4A 7E F9 A5 D9 CB 19 D5 E8 
360 4: OCTET STRING 
: 93 FD 86 7E 


366 26: SEQUENCE { 


368 9s OBJECT IDENTIFIER data 

379 292 SEQUENCE 4 

381 6: OBJECT IDENTIFIER id-Gost28147-89 

389 19: SEQUENCE (1 

391 8: OCTET STRING B7 35 El 7A 07 35 A2 ID 

401 7: OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet 
: } 
: } 

410 12: [0] 39 Bl 8A F4 BF A9 E2 65 25 B6 55 C9 


} 
} 


| >GostR3410-2001-keyagree.bin 
| MIIBPAYJKoZIhvcNAOcDOIIB1TCCAZECAOIxggFOoYIBTAIBA6BloWMwHAYGKOUD 
AgITMBIGByqFAwICJAAGByqFAwICHgEDOWAEOLNVOfRngZcrpcTZhB8n-*4HtCDLm 
Wow Ra dd LI cu ds 
[|L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKOUDAgIfATCBszCBsDCB 
| gTBEMR8wHOYDVOODDBZHb3NOU jMOMTAtMjAwMSBleGFtcGxlMRIwEAYDVQOKDAlD 
| con1wdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3NOU jMOMTAt 
|MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQOqMCgEIBajHOfOTukN 
8ex0aQRoHsefOu240x8dSn75pdnLGdXoBAST/YZ-*MDgGCSqGSIb3DQEHATAdBgYq 
hOMCAhUwEwQItzXhegclohOGByqFAwICHwGADDmxivS/qeJlJbZVyQ-- 
| «GostR3410-2001-keyagree.bin 
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9.3. Enveloped Message Using Key Transport 
This message is encrypted using the sample certificate from Section 
4.2 of [CPPK] as a recipient certificate. The private key 'd' from 


the same section can be used to decrypt this message. 


0 423: SEQUENCE (1 


4 9: OBJECT IDENTIFIER envelopedData 
15 408: [0] 4 
19 404: SEOUENCE 4 
23 1-3 INTEGER 0 
26 339: SET ( 
30. 3395: SEOUENCE 4 
34 I: INTEGER 0 
3T 129: SEQUENCE { 
40 109: SEQUENCE { 
42 3ds SET { 
44 29: SEQUENCE 4 
46 33 OBJECT IDENTIFIER commonName 
51 22: UTF8String 'GostR3410-2001 example’ 
: } 
E } 
75 18: SET { 
77 1:6: SEQUENCE 4 
79 3% OBJECT IDENTIFIER organizationName 
84 9: UTF8String 'CryptoPro' 
: } 
} 
95 11 SET { 
97 9: SEQUENCE { 
99 3: OBJECT IDENTIFIER countryName 
104 2 PrintableString 'RU"' 


} 
A } 
108 41: SET 1 


110 39: SEQUENCE 1 
112 9: OBJECT IDENTIFIER emailAddress 
123 26: IA5String ’GostR3410-2001@example.com’ 
: } 
} 
: } 
151 16: INTEGER 


2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 


: } 
169 28: SEQUENCE { 


171 6: OBJECT IDENTIFIER id-GostR3410-2001 
179 18: SEQUENCE { 
181 TR OBJECT IDENTIFIER 
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: id-GostR3410-2001-CryptoPro-XchA-ParamSet 
190 Ts OBJECT IDENTIFIER 
4 id-GostR3411-94-CryptoProParamSet 
} 
: } 
199 167: OCTET STRING, encapsulates { 


202 164: SEQUENCE { 
205 40: SEQUENCE { 


207 32: OCTET STRING 
E 6A 2F A8 21 06 95 68 9F 9F E4 47 AA 9E CB 61 15 
2B 7E 41 60 BC 5D 8D FB F5 3D 28 1B 18 9A F9 75 


241 4: OCTET STRING 

$ 36 6D 98 B7 

: } 
247 120: [0] 4 
249 grs OBJECT IDENTIFIER 

: id-Gost28147-89-CryptoPro-A-ParamSet 
258 99: [0] ( 
260 28: SEQUENCE { 
262 6: OBJECT IDENTIFIER id-GostR3410-2001 
270 18: SEQUENCE { 
272 7: OBJECT IDENTIFIER 

: id-GostR3410-2001-CryptoPro-XchA-ParamSet 
281 Ts OBJECT IDENTIFIER 


id-GostR3411-94-CryptoProParamSet 
} 
: } 
290 67: BIT STRING encapsulates { 
293 64: OCTET STRING 
: 4D 2B 2F 33 90 E6 DC A3 DD 55 2A CD DF EO EF FB 
31 F7 73 7E 4E FF BF 78 89 8A 2B C3 CD 31 94 04 
4B OE 60 48 96 1F DB C7 5D 12 6F DA B2 40 8A 77 
B5 BD EA F2 EC 34 CB 23 9F 9B 8B DD 9E 12 CO F6 
} 
: } 
359 8: OCTET STRING 
$ 97 95 E3 2C 2B AD 2B 0C 
} 
} 
} 
} 
: } 
369 56: SEQUENCE { 


T 


371 9: OBJECT IDENTIFIER data 

382 295 SEQUENCE { 

384 6: OBJECT IDENTIFIER id-Gost28147-89 

392 Lg: SEQUENCE ( 

394 8: OCTET STRING BC 10 8B 1F OB FF 34 29 
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404 qe OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet 


) 
: } 
413 12: [0] AA 8E 72 1D EE 4F B3 2E E3 OF Al 37 
E ) 
) 
) 
) 


[»GostR3410-2001-keytrans.bin 

| MI [BpwYJKoZ IhvcNAQcDoI IBMDCCAZQCAQAxggF TMI IBTwIBADCBgTBtMR8wHQYD 
| VOODDBZHb3N0UjMOMTAtMjAwMSBleGFt cGx 1MRIWEAYDVQQKDA1Dcn1wdG9Qcm8x 
| CZAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3NOU jMOMTAtMjAwMUBleGFt 
| cGx1LmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKOUDAgIkAAYH 
| KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfvl1PSgbGUr5 
dOOENm2Yt6B4BgcqhOMCAh8BoGMwHAYGKOUDAgITMBIGByqFAwICJAAGByqFAwIC 
HgEDQwAEQEOrLzOQ5tyj3VUqzd/g7/sx93N-Tv-4/elImKK8PNMZQESw5gSJYf28dd 
| En/askCKd7W96vLsNMs jn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSgGSIb3DOEHATAd 
| BgY ghOMCAhUwEwOIvBCLHwv /NCkGBygFAwICHwGADKgOoch 3uT 7Mu4w+hNw== 

| <GostR3410-2001-keytrans.bin 


10. ASN.1 Modules 
Additional ASN.1 modules, referenced here, can be found in [CPALGS]. 
10.1. GostR3410-EncryptionSyntax 


GostR3410-EncryptionSyntax 
{ iso(1) member-body (2) ru(643) rans(2) cryptopro (2) 
other(1) modules(1) gostR3410-EncryptionSyntax(5) 2 } 
DEFINITIONS ::= 
BEGIN 
-— EXPORTS All -- 
-- The types and values defined in this module are exported for 
-- use in the other ASN.1 modules contained within the Russian 
-- Cryptography "GOST" & "GOST R" Specifications, and for the use 
-- of other applications which will use them to access Russian 
-- Cryptography services. Other applications may use them for 
-- their own purposes, but this will not constrain extensions and 
-- modifications needed to maintain or improve the Russian 
-- Cryptography service. 
IMPORTS 

id-CryptoPro-algorithms, 

gost28147-89-EncryptionSyntax, 

gostR3410-94-PKISyntax, 

gostR3410-2001-PKISyntax, 

ALGORITHM-IDENTIFIER, 

cryptographic-Gost-Useful-Definitions 
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FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] 


{ iso(1) member-body(2) ru(643) rans(2) 
cryptopro(2) other(1) modules (1) 
cryptographic-Gost-Useful-Definitions (0) 

id-GostR3410-94 

FROM GostR3410-94-PKISyntax -- in [CPALGS] 
gostR3410-94-PKISyntax 

id-GostR3410-2001 

FROM GostR3410-2001-PKISyntax -- in [CPALGS] 
gostR3410-2001-PKISyntax 

Gost28147-89-ParamSet, 

Gost28147-89-EncryptedKey 


FROM Gost28147-89-EncryptionSyntax -- in [CPALGS] 


gost28147-89-EncryptionSyntax 
SubjectPublicKeyInfo 


} 


FROM PKIX1Explicit88 {iso(1) identified-organization (3) 
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 


id-mod(0) id-pkixl-explicit-—88 (1) } 
; 
-- CMS/PKCS47 key agreement algorithms & parameters 
Gost28147-89-KeyWrapParameters ::- 
SEQUENCE 4 
encryptionParamSet Gost28147-89-ParamSet, 


ukm OCTET STRING (SIZE (8)) OPTIONAL 


} 


id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER 
( id-CryptoPro-algorithms keyWrap(13) cryptoPro(1) 


id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::- 
( id-CryptoPro-algorithms keyWrap(13) none(0) ) 


Gost28147-89-KeyWrapAlgorithms  ALGORITHM-IDENTIFIER 


{ Gost28147-89-KeyWrapParameters IDENTIFIED BY 
id-Gost28147-89-CryptoPro-KeyWrap } | 
{ Gost28147-89-KeyWrapParameters IDENTIFIED BY 
id-Gost28147-89-None-KeyWrap ) 
} 
id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER 
{ id-CryptoPro-algorithms 
gostR3410-2001-CryptoPro-ESDH(96) } 
id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER 
{ id-CryptoPro-algorithms 
gostR3410-94-CryptoPro-ESDH(97) } 
-- CMS/PKCS47 key transport algorithms & parameters 


} 


re | 


—- OID for CMS/PKCS#7 Key transport is id-GostR3410-94 from 
=- GostR3410-94-PKISyntax or id-GostR3410-2001 from 


a GostR3410-2001-PKISyntax 
—- Algorithms for CMS/PKCS#7 Key transport are 
=- GostR3410-94-PublicKeyAlgorithms from 
== GostR3410-94-PKISyntax or 
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=- GostR3410-2001-PublicKeyAlgorithms from 

=- GostR3410-2001-PKISyntax 

-- SMIMECapability for CMS/PKCS#7 Key transport are 

m id-GostR3410-94 from GostR3410-94-PKISyntax or 
== id-GostR3410-2001 from GostR3410-2001-PKISyntax 
id-GostR3410-94-KeyTransportSMIMECapability 


OBJECT IDENTIFIER ::= id-GostR3410-94 
id-GostR3410-2001-KeyTransportSMIMECapability 

OBJECT IDENTIFIER ::= id-GostR3410-2001 
GostR3410-KeyTransport ::= 

SEQUENCE (1 


sessionEncryptedKey Gost28147-89-EncryptedKey, 
transportParameters [0] 
IMPLICIT GostR3410-TransportParameters OPTIONAL 
} 
GostR3410-TransportParameters ::= 
SEQUENCE { 
encryptionParamSet Gost28147-89-ParamSet, 
ephemeralPublicKey [0] 
IMPLICIT SubjectPublicKeyInfo OPTIONAL, 
ukm OCTET STRING ( SIZE(8) ) 
} 
END -- GostR3410-EncryptionSyntax 


10.2.  GostR3410-94-SignatureSyntax 


GostR3410-94-SignatureSyntax 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 
other(1) modules(1) gostR3410-94-SignatureSyntax(3) 1 ) 
DEFINITIONS ::= 
BEGIN 
—- EXPORTS All -- 
-- The types and values defined in this module are exported for 
—- use in the other ASN.1 modules contained within the Russian 
-- Cryptography "GOST" & "GOST R" Specifications, and for the use 
— of other applications which will use them to access Russian 
-- Cryptography services. Other applications may use them for 
-- their own purposes, but this will not constrain extensions and 
-- modifications needed to maintain or improve the Russian 
-- Cryptography service. 
IMPORTS 

gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER, 

cryptographic-Gost-Useful-Definitions 

FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] 

( iso(1) member-body(2) ru(643) rans(2) 
cryptopro(2) other(1) modules (1) 
cryptographic-Gost-Useful-Definitions(0) 1 ) 
id-GostR3410-94, 
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GostR3410-94-PublicKeyParameters 
FROM GostR3410-94-PKISyntax -- in [CPALGS] 
gostR3410-94-PKISyntax 
, 
-—- GOST R 34.10-94 signature data type 
GostR3410-94-Signature ::= 
OCTET STRING (SIZE (64)) 
—- GOST R 34.10-94 signature algorithm & parameters 
GostR3410-94-CMSSignatureAlgorithms  ALGORITHM-IDENTIFIER 
( GostR3410-94-PublicKeyParameters IDENTIFIED BY 
id-GostR3410-94 ) 
) 


END -- GostR3410-94-SignatureSyntax 
10.3.  GostR3410-2001-SignatureSyntax 


GostR3410-2001-SignatureSyntax 
{ iso(1) member-body(2) ru(643) rans(2) cryptopro (2) 
other(1) modules(1) gostR3410-2001-SignatureSyntax(10) 1 
DEFINITIONS ::- 
BEGIN 
— EXPORTS All -- 


-- The types and values defined in this module are exported for 


-- use in the other ASN.1 modules contained within the Russian 


May 2006 


-- Cryptography "GOST" & "GOST R" Specifications, and for the use 


-- of other applications which will use them to access Russian 
-- Cryptography services. Other applications may use them for 


-- their own purposes, but this will not constrain extensions and 


-- modifications needed to maintain or improve the Russian 
-- Cryptography service. 
IMPORTS 
gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER, 
cryptographic-Gost-Useful-Definitions 


FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] 


{ iso(1) member-body(2) ru(643) rans(2) 
cryptopro(2) other(1) modules (1) 
cryptographic-Gost-Useful-Definitions(0) 1 ) 

id-GostR3410-2001, 
GostR3410-2001-PublicKeyParameters -- in [CPALGS] 
FROM GostR3410-2001-PKISyntax 
gostR3410-2001-PKISyntax 
—- GOST R 34.10-2001 signature data type 
GostR3410-2001-Signature ::= 
OCTET STRING (SIZE (64)) 
—- GOST R 34.10-2001 signature algorithms and parameters 
GostR3410-2001-CMSSignatureAlgorithms 
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ALGORITHM-IDENTIFIER ::= 4 
1 GostR3410-2001-PublicKeyParameters IDENTIFIED BY 
id-GostR3410-2001 } 
} 


END -- GostR3410-2001-SignatureSyntax 


Tb. 
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